There is, and will continue to be, advances and changes in how enterprises conduct business. Whether these advances and changes occur through growing competition and globalization, mergers and acquisitions, or revamping of business models, the key for success will often depend on how quickly the enterprise's information technology (IT) organization can adapt to evolving business needs. Therefore, a major challenge to these enterprises is how they handle change.
For organizations to enable business agility, they must ensure that enterprise applications are not only high-performance business engines driving efficiencies, but also that they become flexible building blocks of future business systems. A recent promising solution has risen in the form of services. A service, such as a Web service or program, may represent a self-contained, self-describing piece of application functionality that can be found and accessed by other applications. A service may be self-contained because the application using the service does not have to depend on anything other than the service itself, and may be self-describing because all the information on how to use the service can be obtained from the service itself. The descriptions may be centrally stored and accessible through standard mechanisms.
Instead of requiring programmers to establish and maintain links between applications, services may be loosely coupled, making connections simpler and more flexible, and allowing application architects to more easily find and understand services offered by other cooperative applications. However, a problem that exists with services is that they are often designed to expose functionality of individual applications and, thus, may be too limited to be efficient building blocks for enterprise-wide business processes. A solution to this shortfall has been the migration to a Service Oriented Architecture (SOA). The SOA may use an open architecture middleware, which builds on the benefits of services. An example of an SOA can be found in the Enterprise Services Framework (ESF), which is commercially available from SAP AG, Walldorf, Germany. The term “SOA” may also be used to refer to “distributed objects” architecture, such as CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Component Object Model).
An SOA may enable the abstraction of business objects, modeled as services (also referred to as enterprise services), from actual applications. Aggregating services into business-level enterprise services may provide more meaningful building blocks for the task of automating enterprise-scale business scenarios. Enterprise services allow IT organizations to efficiently develop composite applications e.g., applications that compose functionality and information from existing systems to support new business processes or scenarios.
An SOA may also enable the use of an enterprise services repository. The enterprise services repository may store relevant preexisting enterprise services and may make them available for use by, for example, selected partners and customers. By using the enterprise services repository, these selected partners and customers can use the preexisting enterprise services to facilitate the implementation of new services and corresponding business objects. The term business object (BO) represents a physical or logical object that may be significant to a business, such as a purchase order. An “object” generally refers to a software bundle of variables (e.g., data) and related methods. For example, in object-oriented programming, an object may be a concrete realization (instance) of a class that consists of data and the services associated with that data. An example of a business object is a purchase order business object having data and related methods. When a purchase order business object is instantiated, a user may interact with the purchase order by, for example, providing data for fields in the purchase order.
Enterprise services based on business objects, however, face limitations when the services are used in user interface scenarios. In particular, user interface related features, such as success or error messages, copy or paste, and save or load draft, have no business significance. User interface scenarios may thus not be conveniently represented as, or supported by, enterprise services without impacting the design of the underlying business objects.
In a conventional user interface scenario in an SOA, a user interface may fire an event trigger, such as a “Save” event trigger. A service manager may receive the trigger and send a “Save” service operation request to one or more business objects. Some of the business objects may complete the “Save” service operation successfully and raise a success message independently of other business objects. Other business objects, on the other hand, may not complete the “Save” service operation successfully and may raise an error message independently of other objects. Business objects, however, may not collectively raise a single success message or a single error message in response to a single user interface event. When a business object raises an error message independently of others, the aggregation of the error messages for a user display may not be possible. In addition, error messages from business objects may not be suitable for a user interface.
A user interface may also display fields from a node from a business object to a user. Because a business object may not be designed for a user interface, only a subset of the fields may be displayed. Even if a user interface displays only a subset of the fields, however, all fields from a business object may need to be transported to a user interface over networks because removing fields from nodes of a business object may not be possible. This may affect the memory resource management of client systems, server systems, and networks included with or connected to an SOA. In addition, the mapping of error messages originating from fields in nodes of a business object, which may not be displayed on the screen of a user interface, may not be possible. As a result, a user may see an error message unrelated to what the user is viewing on a user interface.
In the view of the foregoing, there is a need for systems and methods for providing an infrastructure to support user interface scenarios in, for example, an SOA, without impacting the design of the underlying business objects.